\documentclass{article}

%\usepackage[latin1]{inputenc}

% \usepackage[latin1]{inputenc}
 \usepackage[brazil]{babel}
%\usepackage[T1]{fontenc}		% fontes PS com acentos
%\usepackage[brazil]{babel}	
\usepackage[utf8]{inputenc}
% \usepackage{amsmath}
% \usepackage{amsfonts}
% \usepackage{amssymb}
 
\title{ A Methodology for Building \\ Service-Oriented Applications  in the presence of \\
Non-Functional Properties \\ {\it Precisions on the problem addressed and justification of the hypothesis and approach}}
\author{Plácido A. Souza Neto}
%\date{\today} 
 
\begin{document}
 
\maketitle 

The objective of this document is to provide precisions and address the questions stated about the methodology that we propose for addressing the specification, modeling and implementation of non functional requirements for service oriented applications. In order to better organize and explain our ideas and precisions we organized the questions into 7 sections. In each section we enumerate the questions and then we propose a general discussion for answering partially or totally to them. Partial responses are due to the complexity of the questions/suggestions that imply work that will be done after the exam for preparing the final version of the dissertation document.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Background}
\label{sec:backgroud}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
1 - Qual a no\c c\~ao de ``confiabilidade'' usada no trabalho? Apesar de constar
no t\'itulo (``A methodology for building reliable service-based applications'') e
em v\'arias partes do documento, a metodologia proposta e os meta-modelos n\~ao
apresentam nenhuma caracter\'istica que sugira o desenvolvimento de aplica\c
c\~oes deste tipo. Na pr\'atica, a proposta da tese aparenta ter sido concebida
para o desenvolvimento de aplica\c c\~oes orientadas a servi\c cos em geral.      
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
3 - Al\'em da necessidade de remo\c c\~ao do termo ``reliable'' no t\'itulo,
sugiro que o t\'itulo da tese tamb\'em deveria considerar o fato de que
aplica\c c\~oes que tem servi\c cos como elementos de primeira classe s\~ao
referidas na literatura como ``service-oriented applications'' e n\~ao
``service-based applications''. N\~ao sei se houve uma discuss\~ao sobre isto,
mas esta diferen\c ca \'e significativa.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
4 - \'E preciso explicar no texto o que \'e uma aplica\c c\~ao orientada a
servi\c co confi\'avel, ou seja, qual a no\c c\~ao de ``confiabilidade''
adotada. Observe que ``confiabilidade'' tamb\'em \'e um RNF. Caracterizar bem a
confiabilidade destas aplica\c c\~oes ajudaria a entender como a metodologia
trata as particularidades deste requisito n\~ao funcional. Neste ponto, vale a
pergunta: e se as aplica\c c\~oes precisassem ser ``seguras'' (outro requisito
n\~ao funcional), a metodologia poderia ser tamb\'em aplicada?      
\end{quotation}

%\begin{quotation}\sf\footnotesize
%\noindent
%9 - Verificar a frase ``\ldots some proposals extend WSDL adding behavioral
%characteristics, such as PEWS[27], BPEL4WS\ldots'' Observe que BPEL4WS n\~ao \'e uma
%extens\~ao de WSDL. WSDL \'e uma nota\c c\~ao para defini\c c\~ao de interface de servi\c cos e
%WS-BPEL \'e uma notao para composi\c cao de servi\c cos, ou seja, s\~ao nota\c c\~oes
%com prop\'ositos muito distintos. Considere reescrever esta frase.    
%\end{quotation} 

\begin{quotation}\sf\footnotesize
\noindent
12 - Rever ou explicar a frase a seguir: ``The design addresses the functional
requirements while architecture provides the non-functional requirements like
scalability, reliability and performance are realized.'' Esta frase sugere que o
projeto (design) trata os requsitos funcionais enquanto a arquitetura trata os
RNFs. Na pr\'atica, no entanto uma diferen\c ca b\'asica destes requisitos n\~ao \'e a etapa de desenvolvimento em que eles s\~ao tratados, mas o fato de que normalmente
os requisitos funcionais est\~ao confinados (ou s\~ao implementados) em elementos
pontuais da implementa\c c\~ao. Por sua vez, os RNFs s\~ao pervasivos, ou seja, est\~ao
normalmente espalhados em toda a implementa\c c\~ao. Por exemplo, para ser seguro,
todas as partes do sistema precisam ser seguras.       
\end{quotation}

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Non functional properties and service oriented applications}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
Expressing and enforcing non functional properties for distributed systems is a well-known problem with  several associated existing solutions that have modeled thoroughly  them for providing middleware services in object oriented solutions like CORBA and component oriented solutions like EJB. Models and protocols have been defined in the distributed systems and the database domains for dealing with non-functional requirements that concern for example, security , fault tolerance (e.g, transaction monitors, synchronization protocols like 2PC), persistence. Lately service oriented applications, call for approaches that can include these aspects trying to be loyal to the facility of construction philosophy. Some solutions leave this task to the middleware infrastructure (e.g., petals \footnote{http://petals.ow2.org} offers some non-functional services), to the engines that execute them. Other approaches  include the code that implements non-functional properties, as protocols within the coordination code  that implements the application logic of service oriented applications or within the communication protocol used for calling services methods (e.g. data encryption of SOAP messages). This later approach is particular to approaches stemming from the Business Process domain (BPM  \cite{bpmn}) and also to WS-* standards. 

In general, these approaches suppose a good knowledge of the programmer who is in charge in implementing and running the non-functional services according to given application requirements. Our work benefits with these previous results in order to provide a software oriented methodology that can include in the different development phases the specification of non-functional properties, their modeling and implementation. Thereby, our methodology provides meta-concepts that can be specialized in order to model different non- functional properties (security, atomicity, exceptions, persistency)  and associated them to the service coordination. The scientific challenge was to analyze approaches concerning the non-functional properties and generalize them into the meta-models that are core components of our methodology.

The concept of reliability of service-oriented applications  used in our work is associated to the concepts of {\it correctness}, {\it robustness} and {\it reliability} introduced in  (i) \textit{Design by
Contract} \cite{Meyer92,MeyerN93,Meyer97}, (ii) referred by \cite{Meyer92,Meyer97} and (iii) defined in the database domain. 

\textit{(i) Design by
Contract} defines reliability as a concern that integrates the ability of a software element to perform the tasks as defined in its specification (correctness) and that reacts appropriately to abnormal conditions (robustness). Furthermore,  the notion of contract proposed by \cite{Meyer92,MeyerN93,Meyer97} enables the specification of actions to take when one of these properties is not respected by a service. 

%\begin{itemize}
 % \item Correctness: The ability of software products to perform their exact tasks, 
%as defined by their specification;
  % \item Robustness: The ability of software systems to react appropriately to 
   %abnormal conditions.
  % \item Reliability: A concern encompassing correctness and robustness. As the
  % contracts for service interfaces are designed to ensure the expected result
   %after the task performed by the service, and that if the contract is broken,
   %the service does not apply to the application, we try to ensure the
   %correctness by applying contracts in independent services.
%\end{itemize}

%Concerning robustness, when a contract is broken, the specification 
%describes alternative paths for the user does not notice the error. 

%Thus, we can say that the use of design by contract for services in service-oriented
%applications can ensure the reliability of these kind of applications.     

(ii)  \cite{Meyer92,Meyer97} associates the notion of reliability to the conformance between the requirements specification of a software component and its implementation with the objectives to avoid possible bugs. Thus, reliability is associated to the absence of bugs of a software component with respect to its specification (during the design phase).   
 
 Finally, in the database domain (iii), reliability is often related to a kind of fault tolerance in the sense that a database application is reliable if it handles exception and it ensures that data consistency will be maintained despite possible physical and logic faults [Adiba]. 
 
 %how to reduce bugs by building
%software components on the basis of carefully designed contracts. Inspired on the notion
%of reliability described in this works (``Reliability is even more important
%in object-oriented programming than elsewhere.''), a software component, whether
%a service or not, which is designed based on contracts has reduced the amount of
%bugs, becoming more reliable. In the specific case of services, which are
%loosely coupled components, the specification and verification of these
%contracts must be performed by the services’ orchestrator, who shall verify the
%validity and execution of these contracts.  


 Our work enables the modeling and specification of non functional properties and their associated recovery actions and the way they are associated  to a service coordination expressed as a workflow. In the modeling phase of our methodology, non-functional properties are seen as business rules and constraints (e.g. privacy requirements with respect to data used within the process, temporal constraints on the communication with a service) specified semi-formally and that are part  of  a business process specification (e.g., online purchase process). Along the phases of the methodology these business rules and constraints are modeled using more concrete concepts that lead then to their implementation in executable code.
 
 In our work, not respecting a non functional property expressed in a specification in the design phase,  implies an exceptional behavior of the application. These exceptions are dealt according to predefined actions also expressed in the design phase, oriented to tolerate these exceptions. In consequence, in our work, a reliable service coordination is the one that conforms to a specification and that is exception tolerant, where exceptions concern the violation of  constraints and business rules defined in the specification.  Different to existing works, our approach supposes autonomous services \footnote{A service is autonomous when it does not share its execution state, it can evolve independently of the application that use them, and it does not provide means for controlling its availability.} and does not associate these properties to services but to an application logic implemented as a coordination. Of course, when non-functional properties associated to a service coordination depend on the properties of participating services, the programmer should be aware of that and provide non-functional properties partially, model compensating strategies for ensuring them or at least program recovery actions that can signal an exception when a non-functional property is violated.



%Considering the topics related with service-oriented development and
%non-functional requirement, and even the contribution/discussion given about
%these topics, we decided to change the thesis' title for: ``\textit{A
%Methodology for Building Service-Oriented Application in the Presence of
%Non-Functional Properties}''.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Context}
\label{sec:context}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

 \begin{quotation}\sf\footnotesize
\noindent
10 - Na frase a seguir n\~ao fica claro como MDA alinha os conceitos de RNFs e
SOC: ``MDA [67] is an important approach for the alignment between highlevel
information modelling, non-functional requirements\ldots''. Na pr\'atica, \'e
preciso explicar porque o uso de MDA favorece/ajuda o tratamento de RNFs.
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
20 - Esclarecer o que s\~ao Business Services. Este termo n\~ao \'e comum na \'area de servi\c cos. 
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
22 - N\~ao tenho certeza, mas acredito que alguns elementos dos metamodelos da
$\pi$SOD-M j\'a tenham sido definidos na SOD-M. Seria interessante, se isto est\'a
acontecendo, destacar estes elementos para deixar claro ao leitor os elementos
que s\~ao exclusivos da $\pi$SOD-M.    
\end{quotation}
 

\begin{quotation}\sf\footnotesize
\noindent
23 - Observando a Figura 4, \'e poss\'ivel observar que $\pi$SOD-M tem as mesmas
etapas de SOD-M, mas com foco no RNFs. Isto sugere (posso estar enganado) que toda a
parte ``funcional'' foi aproveitada na SOD-M. Isto \'e verdade?   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
30 - N\~ao est\'a muito clara (justificada) a necessidade de um ``Process Model'' e
um ``Composition Model''. Observe que em nota\c c\~oes como WS-BPEL os elementos destes
dois modelos est\~ao de certa forma juntos, ou seja, talvez seja interessante
justificar porque a metodologia adota esta separa\c c\~ao.    
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
35 - Quem \'e o ``Application designer''? Qual o perfil? \'e algu\'em de neg\'ocio ou de
TI? Isto \'e importante estar definido na metodologia, pois provavelmente existem
v\'arios atores (business expert, qos expert, TI expert) envolvidos nas v\'arias
etapas da metodologia. Por exemplo, algu\'em de neg\'ocio seria capaz de definir uma
express\~ao como estas apresentadas na Figura 20 (e.g., $\#$bankBlance $>$
paymentValue \&\& \ldots ). Veja ainda na p\'agina 85: quem \'e o
``designer'' referido na frase ``The designer must specify\ldots''.      
\end{quotation}

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Building service oriented applications using software engineering methodologies}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

Our work extends the existing methodology SOD-M that provides meta-models for modeling and implementing services oriented applications. The objective of the methodology is support the construction of such kind of applications and ensuring their conformance to its specification as stated by user requirements during the analysis phase. Providing a conceptual framework based on meta-models for modeling a service oriented application ensures that the resulting implementation will conform to user requirements. On the other hand, thanks to transformations among models, the programmer can rely on a partial automatic generation of the models of the application. This reduces the programming effort and provides  an abstract vision of the application that can be important for following the construction process.

From our point of view, non-functional properties are in general not considered when a service oriented application is modeled. Methodologies in general focus on the application logic  and then rely on  programmers for implementing non-functional properties either by coding them directly (e.g., handling exceptions) or by configuring the services provided by the middleware (e.g., persistence or transactional properties). We believe that it is possible to model non-functional properties during the early stages of applications development process and that this can be done using an MDD approach. Therefore, we assume that, at least in the context of service oriented applications, it is possible to propose meta-models that can be specialized for expressing non-functional properties and that can be associated to concepts used for modeling the application logic. Particularly, in the case of SOD-M a service oriented application logic is modeled as a business process that can be implemented by a composing existing artifacts called  (business) services \footnote{Note that the term business services is used to make the difference between the services that participate in the implementation of an application logic from the services used for implementing non functional aspects. For instance, CORBA domain services are those equivalent to  business services. BPMN \cite{bpmn} defines a similar
term called \textit{Service operation}  that
is part of the business process.}. In SOD-M, a business service is represented by a service
(or a service composition) that will implement a task within a  business process. 


%In $\pi$SOD-M the concept of \textit{Business service} represents services
%that are part of a business process. 

%$\pi$SOD-M considers these concepts to cover the non-funcional aspects and
%service-oriented standards for a MDA based development. $\pi$SOD-M inherits all
%the functional part from SOD-M, and includes the elements necessary to model
%non-functional aspecs in terms of \textsc{Policy}.



%MDD is an important approach for aligning information about abstract modeling
%levels and non-functional requirements. In model-based development, the
%information will be refined at each level through model transformation,
%thereby the NFRs can be best described their concepts and needs in the
%application development.

%MDD has beed increasingly employed to guide development with focus on the
%generation of code from models. The modeling aspects of non-functional
%properties remains difficult. Models that describe non-functional properties may be used
%to express, in the specification phase, transversal characteristics of the
%application.  As the specification of these models is done , essential
%properties are being incremented \cite{Rottger04}.





   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Problem Statement and Hypothesis}
\label{sec:problem_hypothesis}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
2 - Senti falta de justificativas de porque a proposta foi desenvolvida apenas
para Web services. Observe que existem diversos servi\c cos que n\~ao s\~ao Web,
ou seja, n\~ao s\~ao descritos em WSDL, n\~ao s\~ao armazenados em UDDIs e usam outros
protocolos de comunica\c c\~ao diferentes de SOAP.   
\end{quotation} 

\begin{quotation}\sf\footnotesize
\noindent
8 - Por que Web services e n\~ao Servi\c cos foram considerados? Por que o trabalho
considera apenas Web services? Existe uma raz\~ao particular para isto, uma vez
que torna a solu\c c\~ao restrita ao universo de Web Services?  
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
7 - N\~ao h\'a uma discuss\~ao de porque tratar RNF \'e dif\'icil ou porque SOC
facilita o tratamento destes requisitos.
\end{quotation}
 
\begin{quotation}\sf\footnotesize
\noindent
36 - Que linguagens s\~ao estas ``behavioural web service interface languages''?    
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
18 - Senti falta tamb\'em de uma discuss\~ao sobre ``correla\c c\~ao'', ``conflitos'' e
``prioridade'' entre RNFs. Estes dois aspectos s\~ao muito discutidos quando
fala-se em RNFs.   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
27 - Senti falta de uma descri\c c\~ao precisa do que sejam NF-Attributes,
NF-Properties e NF-Requirements. 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
28 - N\~ao entendi a frase ``The quality properties at the system level represent
a behaviour that is part of the workflow.''
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
32 - N\~ao h\'a uma explica\c c\~ao sobre (i) porque a metodologia foi estruturada em
tr\^es vis\~oes (Business, System and Policy) e (ii) como chegou-se a estas tr\^es
vis\~oes.  
\end{quotation} 


\begin{quotation}\sf\footnotesize
\noindent
39 - J\'a existia um metamodelo de PEWS?   
\end{quotation} 


% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Problem: Modeling non functional properties of service oriented applications} 
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

Even with the growing interest in developing higher-level models and design
paradigms, current technology is inadequate both representationally for
expressing such global constraints as formal non-functional requirements (NFRs)
and methodologically for utilizing them \cite{Chung91,MylopoulosBook99}. NFRs
specify global constraints that must be satisfied by the software \cite{RosaC04}. 
%However, this
%kind of requirements are not implemented such as functional requirements. 

Ensuring non-functional properties has been challenging when developing applications because they are both related to the business rules of the application (e.g., defined user rights associated to the execution of applications' functions: only the manager can authorize the modification of a salary.) but also to the technical characteristics of the infrastructure where the application is executed (e.g., the messages transmitted through the network cannot be modified while transmitted). Having a methodology for specifying the application logic and its associated non-functional properties starting in the early phases of the development process is a difficult problem because:
\begin{itemize}
  \item the designer must make the difference between requirements that concern the application logic and the non functional requirements; 
  \item the  non functional requirements specified in an abstract  way (e.g., as business rules) must provide enough information to be translated into the specification of technical aspects implementing a concrete non-functional property. For example, saying that the payment, the authorization of delivering a package and the modification of the stock must be all together successful otherwise they must be undone, can be translated into an atomicity property associated to these operations (i.e., either the three of them are executed or none of them);
  \item  the methodology must provide general enough concepts  for modeling quite different non-functional requirements and strategies to ensure that their abstract specification will lead to the implementation of protocols that will ensure these properties while the application is executed. 
\end{itemize}

In the case of service oriented applications it is particularly difficult to add non-functional properties because in general the existing protocols and models implementing some of them assume that it is possible to have a global control of  the artifacts implementing the application or that at least they export interfaces in order to have information about their execution state, the messages exchanged with others, the conditions in which messages are transmitted on the network. In the case of service oriented applications, the services used as construction units are autonomous, they do not share information about the state and data they manage and there are few engagements with respect to their availability and evolution. This aspect calls for flexible protocols and models that can accept a best effort approach for ensuring non-functional properties.  For example, to provide security, all services of the composition should be safe; to ensure satisfactory
response time, all services of the composition must provide the results obeying
restrictions of the client.  These assumptions cannot be made, and thus in some cases non-functional properties cannot be completely ensured. The methodology should take into consideration this situation in order to reflect it along the different contraction phases.  

 
%However, as services are
%independent components and has a finer granularity, to ensure that services
%constraints are satisfied is a bit easier. As each service provides access to
%its interface, its clients have an opportunity to check if the result satisfies
%or not, even during the execution of the application. Moreover, the guarantee of
%non-functional properties in service composition is not as trivial to solve.
%This occurs because of non-functional requirements, in most cases, have
%distributive characteristics, or even opposite. For example, to provide
%security, all services of the composition should be safe. To ensure satisfactory
%response time, all services of the composition must provide the results obeying
%restrictions of the client.  

%Due to these problems, non-functional properties are treated in services
%in a particular way, for example, most studies attempt to ensure
%specific requirements in the modeling of service-oriented applications.
%Knowing this problem, we try to cover with $\pi$SOD-M a slightly
%more general and abstract approach based on contracts for services. Contracts
%for services can be specified for both services simple or compound.



%_________________________________________________________________________________________
\paragraph{Hypothesis}
%_________________________________________________________________________________________

\begin{enumerate}
\item It is possible to provide a methodology for building service oriented applications that is agnostic of the data models exchanged by the services, the interface definition language used for describing the services interfaces, the protocols and architectures used for calling services,   the composition languages and the execution engines. This implies that our methodology can consider REST and SOAP services with interfaces described in WSDL, semistructured (JSON, XML), unstructured and structured data models, and compositions expressed in any language. 

%Likewise, the proposed methodology ($\pi$SOD-M) can be applied to any service
%approach, not necessarily Web services. $\pi$-PEWS specifications
%can have different types of namespaces, not only WSDL. It is possible to use the
%methodology even if the used approaches are JSON, REST, Java RMI, WCF, and so
%on. As contracts are about functions, the restrictions described  through the
%contracts can used for any approach, not only Web services.

\item We use the notion of service in a general way without necessarily associating it to the Web. A service is a software element implemented by a service provider that exports an interface for calling the service and that is accessible through a network.

\item Business rules and constraints specified as application requirements can be translated into non-functional properties that can be associated to a service composition that implements the application logic of a service oriented application.

\end{enumerate}
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Principles and Approach}
\label{sec:principles}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
11 - Observe na frase a seguir que WSDL e WS-BPEL n\~ao s\~ao ``plataformas de
servi\c co'': ``MDA allows the specification of a system as an abstract model,
which may be realized as a concrete implementation (program) for a particular service
platform (e.g. WSDL, BPEL or PEWS).''    
\end{quotation}

\begin{quotation}\sf\footnotesize 
\noindent
13 - Sugiro que tamb\'em seja discutido na tese o seguinte ponto: associar RNFs a
``composi\c c\~oes de servi\c cos'' ou a ``servi\c cos'' pode ser muito
dif\'icil, pois alguns RNFs s\~ao ``distributivos''. Imagine que o
desenvolvedor define que a composi\c c\~ao (e.g., formada por 5 servi\c cos) \'e segura. Isto implica (mesmo que n\~ao seja dito
pelo desenvolvedor) que todos os servi\c cos precisam ser seguros e que todas as
comunica\c c\~oes entre ele s\~ao seguras. Mas, imagine que um dos servi\c cos
n\~ao \'e seguro. Como esta situa\c c\~ao \'e tratada pela metodologia? Quais os artefatos
gerados no final?      
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
24 - DEVISE \'e uma metodologia?  
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
25 - N\~ao \'e muito claro como um ``requisito n\~ao-funcional'' pode ser representado
por um ``use case''.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
26 - Talvez esteja claro no texto, mas n\~ao ficou claro para mim os mapeamentos
``Constraint'' -> Contract e Contract-> Policy s\~ao realizados.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
29 - Observar esta parte ``$\pi$SOD-M is a MDA (Model Driven Architecture) based
methodology. It provides a framework for building service compositions
considering their non-functional requirements.'' A metodologia fornece um
framework? Os conceitos de metodologia e framework s\~ao muito distintos.   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
31 - Senti falta de uma descri\c c\~ao passo-a-passo da Figura 5, por exemplo,
``Inicialmente tem-se uma especifica\c c\~ao de um processo de neg\'ocio que \'e
transformado em um UseCase model...'' Esta explica\c c\~ao at\'e existe, mas est\'a
dilu\'ida nas p\'aginas subsequentes do texto quando voc\^e diz ``After modelling the
system services and feature...'' (pp. 62). Como esta figura \'e muito importante,
ela deveria ser bem descrita.      
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
33 - Sugiro uma explica\c c\~ao sobre o mapeamento apresentado na Figura 16. Por
exemplo, \'e preciso justificar porque uma ``Business Service'' \'e representado em
UML por um ester\'otipo.  
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
37 - Seria interessante justificar porque a linguagem PEWS foi escolhida para a
implementa\c c\~ao. Isto remete a outro importante, a metodologia \'e desacoplada desta
linguagem, ou seja, ela suportaria a gera\c c\~ao de composi\c c\~oes execut\'aveis em
WS-BPEL?   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
41 - Senti falta dos requisitos do ambiente de desenvolvimento proposto. Veja
que a Figura 41 j\'a mostra a arquitetura. Quais os requisitos que geraram esta arquitetura?
\end{quotation}

\begin{quotation}\sf\footnotesize  
\noindent
42 - O ambiente n\~ao deveria ser estruturado em ``vis\~oes'' como a metodologia?
\end{quotation}


% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Principle}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

The $\pi$-SOD-M development process follows a set of transformation and
editing models (presented in the Figure 5 of the thesis). The methodology
provides a conceptual structure to: (i) capture the system requirements and
specification in high-level abstraction models (represented as computation
independent models, CIMs); (ii) obtain the PIMs (platform independent models)
from such business and specification documents. The platform independent models
(PIMs) are designed to specify the system details (service process); (iii)
transform such models into platform specific models (PSMs) that bundles the specification of the
system with the details of the targeted platform; and (iv) serialize such model
into the working-code that implements the system.

 As our approach is based on contracts for services, the guarantee of
 non-functional properties is directly related to the verification 
 of contracts, inputs and outputs required for a service, or a
composition of services. We propose guidelines for building service compositions that include
 non-functional properties. These aspects are implemented as \textsc{policies}
 for the application services. The design of this aspects integrates both
 functional and non-functional requirements, and the treatment we give to
 compound services are that if there is a conflict in relation to contracts, the contract
 is broken and the composition is not suitable for the application. The Policy
 view concepts (presented in the Figure 6 of the thesis) are used to model the
 non-functional properties for service-oriented applications in $\pi$-SOD-M.
  
 While non-functional requirements express global constraints, non-functional
 attributes (NFAs) model non-fuctional characteristics that can be precisely measured, such as
 \textit{performance} \cite{RosaC04}. This kind of characteristics are closer to
 implementation. In  $\pi$-SOD-M, the non-functional properties are refined
 through the design, being represented as \textsc{constraints} in the high level of
 specification. These \textsc{constraints} are grouped into
 \textsc{contracts} for service, and then refined into \textsc{policies} to
 be verified by the application. Each \textsc{policy} is classified according
 to the type of constraint that is specified, which represents a non-functional
 property.

 We consider a NFR as a group of semantically correlated non-functional
attributes (NFA). For example, \textit{security} is an NFR that
comprises attributes such as \textit{confidentiality} and \textit{integrity}.
The concept of non-functional property brings together all kinds of
software's constraint. Thus, it can be used as a synonym for NFRs or NFAs.
In $\pi$SOD-M, these properties are being refined through the
model transformations, represented as \textsc{constraints}, \textsc{contracts}
and \textsc{policies}. 







%The modeling of business process proposed in $\pi$SOD-M is simpler than
%those seen in the WS-BPEL. In addition we use two models to express: (i) the
%main workflow, and (ii) the relationship of each activity with external services.




% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection {Approach}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

We consider that one of the most important process when designing a system is
the requirement analysis process, especially identifying the non-functional requirements and the system
restrictions. In order to ease the coding process and let the developer focus on
technical issues, the system may be automatically generated, from
the system design. 
 
  
The models proposed by $\pi$SOD-M represent both the cross-cutting
aspects of the application being modelled, as well as the constraints associated
to services in order to automatically generated the system specification code.
From the requirements and business specification documents \cite{scube2010book}, the
$\pi$-UseCase model is build. Based on this model, a sequence of transformations is performed in order to better refine the concepts. The
$\pi$-UseCase model represents the use cases, requirements and
constraints of the application
%, the $\pi$-ServiceProcess model is generated.
 
In $\pi$SOD-M, a \textsc{Use Case} can be related with a set of
\textsc{Constraints} (in $\pi$-UseCase model). In specifying the $\pi$-UseCase
model, \textsc{Constraints} are always associated with a \textsc{Use Case}. As this model is a higher-level modeling,
each constraint is associated with a type of non-functional requirement
(candidate). During the transformations, this service restriction is being
refined in order to have accurate description to describe the desired
non-functional requirement. The \textsc{Constraints} are grouped into
\textsc{Contracts}, where the \textsc{Constraints} of the same use case are
transformed into \textsc{Assertions}, and these \textsc{Assertions} compose a
\textsc{Contract} (in $\pi$-ServiceProcess model).   


The $\pi$-ServiceProcess model describes the business process to be executed,
and their restrictions. These restrictions are represented as \textsc{Contracts}
with common non-functional property (e.g., security) and are grouped into a
\textsc{Policy} (in $\pi$-ServiceComposition model). From the
$\pi$-ServiceProcess model, the $\pi$-ServiceComposition model is generated.
The $\pi$-ServiceComposition model is similar to the previous one. However it
describes which external services are related to each action/operation in the
business process. From the $\pi$-ServiceComposition model it is possible to
generate a specification for any linguage for describing services composition.


The main objective of having two models to describe the service process 
($\pi$-ServiceProcess and $\pi$-ServiceComposition)  is to have a clear
separation of concepts to be modeled at each stage of development. While the
($\pi$-ServiceProcess model describes the business process model, the
$\pi$-ServiceComposition model describes the services needed for its execution.
Although WS-BPEL defines a similar set of concepts, our goal was
also to simplify the description of these process.

The Business and Service views were inherited
from SOD-M \cite{CastroMV11}, while the Policy concepts were designed to cover
the elements and concepts necessary for describing constraints for services. The
Business view defines the the elements to model the business process, while the
Service view defines the elements necessary for design the service-oriented
structure. Thus, the original structure SOD-M was extended to
cover a way to represent the non-functional properties during the project design.



\paragraph{Transformation rules}
All model transformations proposed in $\pi$SOD-M have been described in
natural language. These transformations define the concepts being refined and
 processed at different levels. The ATL language was used
for developing the mapping rules for transformation of models: (i)
\textit{$\pi$-UseCase2$\pi$-ServiceProcess},
(ii) \textit{$\pi$-ServiceProcess2$\pi$-ServiceComposition} and
(iii) \textit{$\pi$-Service\-Composition2$\pi$-PEWS} transformations). 

The transformation between $\pi$-UseCase and $\pi$-ServiceProcess
models defines how the application requirements are represented as a service
process. The transformation process from \textit{$\pi$-ServiceProcess} to
\textit{$\pi$-ServiceComposition} model refines the application
design, and the goal of this transformation is to group all {\sc Contracts}
and {\sc Actions} into {\sc Policies} and {\sc Service Activities},
respectively. And, in the transformations between $\pi$-ServiceComposition and
$\pi$-PEWS meta-models, we propose two groups of rules: those that transform services composition
elements of the $\pi$-ServiceComposition into $\pi$-PEWS \textit{namespace,
alias, service} and \textit{path} elements; and those that transform
\textit{rules} grouped by \textit{policies} ($\pi$-ServiceComposition) into
\textit{A-policy} ($\pi$-PEWS) types.

In most cased, the environment or the designer should verify if
the transformations are valid or not. In the $\pi$SOD-M environment, the
consistency (semantic) of the transformations must be performed by the designer.
If a problem on the transformation is identified, the target model can be
modified.

Since there are more than one language for define
transformation rule, such as QVT and ATL, we omit these ATL transformation
to the reader of the thesis. The transformations in ATL were not included in the
thesis manuscript because the rules have already been described in natural
language. However, as a way of adding value to the the thesis, we will include
 the transformations described in ATL as an Appendix of the thesis.  

\paragraph{Code generation}
As the $\pi$SOD-M methodology is actually decoupled from any language, it is
possible to generate code for $\pi$-PEWS, WS-BPEL, XAML and other languages for
describe business/service process. It is necessary define the meta-model and then
specify the mapping rules (transformations between the models). 


The $\pi$SOD-M methodology proposes a model transformation for generation of
code in $\pi$-PEWS specification. The code is produced from a \textit{$\pi$-PEWS}
model, after it be generated by a model transformation from
\textit{$\pi$-ServiceComposition} model. We used the Acceleo \cite{acceleo}
environment to define and run the transformation rules. After the code
transformation process, a \textit{.pews} file is created.
 
$\pi$-PEWS is a behavioral language for web service
because describe not only the input/output interface of a web service but also
the expected behaviour of its components. The extension of PEWS (for the
generation of $\pi$-PEWS) was inspired by languages like JCML \cite{CostaMMN12},
JML \cite{LeavensKP07} and Eiffel \cite{Meyer92b}, which describe contract to
specify the behavior of a function. Thus, in $\pi$-PEWS this behaviour can be
specified by defining the order the services will be executed (in the business
process) and its input/output restrictions.  

% Some proposals specify services and their compositions by adding
% behavioral characteristics, such as $\pi$-PEWS \cite{Placido2010LTPD}, or even
% WS-BPEL \cite{ws-bpel2}. 


The $\pi$-PEWS language was chosen for be the implementation environment for
$\pi$SOD-M because we have been working with this language throughout the our research group. We
develop the $\pi$-PEWS meta-model, based on the $\pi$-PEWS sintaxis, and then the
mapping rules between PIM and PSM were defined.

The implementation of the $\pi$SOD-M environment, considering the ATL
and Acceleo transformaions includes: (i) all $\pi$SOD-M meta-models, (ii)
editors for each model for the applications being developed, and (iii) the
plugins for the transformations defined by the methodology.

 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Validation}
\label{sec:validation}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Question}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
5 - Deveria haver uma discuss\~ao na tese sobre a consist\^encia dos modelos.     
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
6 - Por que n\~ao foi feita nenhuma valida\c c\~ao ``quantitativa'' para mostrar quanto
a metodologia proposta ``facilita o desenvolvimento de aplica\c c\~oes
orientadas a servi\c co'' (ver defini\c c\~ao de valida\c c\~ao na pp. 116)? N\~ao h\'a evid\^encias de que a
metodologia facilita o desenvolvimento de aplica\c c\~oes orientadas a servi\c co.
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
43 - Ao inv\'es de ``estudos de caso'' colocaria ``Examples''. Removeria o Estudo
de Caso 1, pois ele foi usado em toda a tese e todos os principais elementos j\'a
foram apresentados no Cap\'itulo 3 (inclusive as figuras s\~ao as mesmas). 
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
44 - N\~ao fica claro o que \'e a ``an\'alise qualitativa'' mencionada.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
45 - Explicar melhor os trabalhos futuros. Evite itemiz\'a-los.
\end{quotation}
  
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Discussion}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -



From the examples\footnote{Considering Chapter 5, we will use the term
``\textbf{\textit{Examples}}'' for the case studies presented. Similarly, instead of ``\textit{Validation}'' term,
we will use the term ``\textbf{\textit{Evaluation}}'', in Chapter 5, as a
way to better represent what was done.} (``\textit{case studies}'') that were used to the evaluation of
the proposed methodology, we could verify that the restrictions on services can be
modeled from the early stages of development, not leaving it to the programming
language, or to the programmer to resolve this type of problem.

We also note that a MDA-based methodology provides a reasonable
strutucure for modeling applications, especially those that consider non-functional
properties. However, while MDA uses a object-oriented modeling language (\textit{i.e.},
UML) as the core technology, it does not insists on the importance of precise,
formal  and automated  transformations model for the design and implementation
of the mappings  PIMs-to-PSMs rules, or PSMs to code. MDA does not provide
mechanisms to verify the consistency of the models developed. For this, there
are some studies that focused on check consistency of these models using a formal
approach \cite{Varro04,PaigeV12}.

The verification of syntactic consistency of the models is performed by
the some MDA tools, such as the \textit{Eclipse Modeling}. As there was the
initial focus of our work verify the semantics of the models and of the
generated code (in order to analyze its consistency), we did not present in the
thesis' manuscript a discussion on this subject. However, we have identified as
future work \footnote{Considering Chapter 6, we will
detail each future work instead of itemises them.} (pg. 146) the need for
formalize the transformation rules proposed by $\pi$SOD-M. 
 

We have the intention to perform a quantitative analysis for the final version
of the thesis' manuscript. We intend to perform an analysis of the code generated
in $\pi$-PEWS. Since the methodology generates the specification
of the application, describing the workflow and contracts, we will make a
comparison with a similar approach \cite{Milanovic2006} that considers some kind of
specification language, such as the method B. 
 

 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  
\section{Systematic Review}
\label{sec:sytematic} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
15 - Acredito que as Research Questions poderiam ser melhor formuladas. Por
exemplo, em rela\c c\~ao RQ1 (``How are NFRs modelled by existing methodologies for
developing reliable Web services''), as nota\c c\~oes para expressar RNFs quase
nunca est\~ao associadas a metodologias de desenvolvimento de software (muito menos a
metodologias -ainda muito escassas - de desenvolvimento orientado a servi\c
co). A maioria das nota\c c\~oes para expressar RNFs s\~ao definidas
isoladamente, pois o tratamento explícito de RNFs ainda \'e muito raro. Acredito que por conta disto
voc\^e n\~ao encontrou i-star, GRL, NFR e KAOS, pois exceto NFR, os outros n\~ao
est\~ao integrados a nenhuma metodologia de desenvolvimento de software.         
\end{quotation}


 
\begin{quotation}\sf\footnotesize
\noindent
16 - N\~ao entendi a RQ4 e nem as poss\'iveis respostas a RQ6  
\end{quotation}
\begin{quotation}\sf\footnotesize
\noindent
21 - Uma das RQs poderia ser ``metodologias fazem o desenvolvimento de
composi\c c\~oes por orquestra\c c\~ao ou por coreografia?'' Isto mereceria tamb\'em uma
discuss\~ao na tese, pois s\~ao as estrat\'egias normalmente usadas na computa\c c\~ao
orientada a servi\c cos. Ainda relacionado a isto, outro ponto que deveria ter sido
discutido na tese \'e o fato de que metodologias para este tipo de desenvolvimento
tem como etapas principais a ``sele\c c\~ao'' e a ``combina\c c\~ao'' de servi\c cos. Compare
estas etapas com as etapas tradicionais.       
\end{quotation}

 
\begin{quotation}\sf\footnotesize
\noindent
17 - Observando os strings utilizados para a busca nas bases bibliogr\'aficas, \'e
poss\'ivel observar que: no mundo de servi\c cos, o termo QoS \'e muito mais
comum do que ``non-functional requirements'' e s\~ao usados como sin\^onimos na \'area. Isto
pode ter tido um impacto muito grande nos resultados retornados.   
\end{quotation}

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Discussion}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

The main goal is to define the RQ4 was check if there is any `` standard''
or classification of NFR for service-oriented development. With this question we
wanted to verify whether it existed approaches to working with NFRs services in
the context of a methodology for service-oriented development. Thus, the results
about KAOS and i-star, for example, were not returned as a result.

About RQ6, in our analysis we would like to know if the non-functional
requirements addressed in the work analyzed consider service composition or not.


Finally, a change in the search query to consider QoS, would be:
\textsc{[Non-Functional requirements or Non-Functional properties or Non-Functional
attributes or QoS] And [Service oriented application development or Web
Service based applications development or Service Composition development]}

The challenge to the use of MDD in modeling of cross-cutting aspects of the
application from the more abstract level of design is the ability to use
different types of models for different purposes and understand the differences
between the terminologies for the non-functional properties
\cite{LimingZhu2009}.


  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\section{Related Works and Comparison}
\label{sec:relatedWorks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
14 - Senti falta de cita\c c\~oes a trabalhos de John Mylopoulos, cujo livro e
artigos s\~ao os mais importantes na \'area de RNFs. Em particular, o livro
``Non-Functional Requirements in Software Engineering'' \'e uma esp\'ecie de
``bíblia'' da \'area. Al\'em desta, existe uma vasta literatura sobre RNFs n\~ao
mencionada no texto: KAOS, i-star, NFR, URN/GRL (padr\~ao da ITU-T). A quase totalidade dos
elementos presentes nos metamodelos propostos j\'a constam nos trabalhos
mencionados acima, e.g., NF-Attribute, NF-Requirement, NF-Action, NF-Properties.
Inclusive, j\'a existem tamb\'em metamodelos e UML profiles para modelagem de RNFs. 


Por fim, tamb\'em senti falta de men\c c\~ao aos padr\~oes WS-* que se
relacionam a RNFs: WS-Policy, WS-SecurityPolicy, WS-Reliability, WS-Transaction,
e ``Quality Model for Web Services''.
\end{quotation}  

\begin{quotation}\sf\footnotesize
\noindent
19 - Observe que o trabalho de D'Ambrogio [34] tamb\'em tem MDA, RNFs e servi\c cos,
ou seja, ele deveria estar na mesma \'area que a proposta da tese na Figura 3. 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
38 - Por que as pol\'iticas n\~ao s\~ao descritas em WS-Policy? Existe tamb\'em
metamodelo deste padr\~ao? WS-Policy \'e amplamente conhecido e j\'a suportado por
diversos ambientes de execu\c c\~ao para aplica\c c\~oes orientadas a servi\c cos.   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
40 - Por que as regras de transforma\c c\~ao n\~ao foram descritas em ATL? 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
34 - Observe que processos em WS-BPEL possuem muito mais do que ``sequence of
activities'' (ver frase ``It can be visualized with a flowchart as a sequence of
activities with interleaving decision points''). Na pr\'atica, por tr\'as desta
minha observa\c c\~ao est\'a a constata\c c\~ao de que o modelo para defini\c c\~ao de processos proposto ( PI-ServiceProcess) \'e muito mais simples do aqueles apresentados em
nota\c c\~oes como URN e WS-BPEL (usadas com o mesmo objetivo e que j\'a possui
metamodelos).    
\end{quotation}

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Discussion}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

The main goal of $\pi$SOD-M is to provide a way for helping the development
of service-oriented application applications in the presence of non-functional
properties. Our work targets the specification and programming web application,
including these non-functional aspects (i.e., atomicity, security, performance,
persistence). In contrast to approaches such as WS-* , our work
specifies \textit{policies} for service compositions in an orthogonal way,
\textit{i.e} separating the specification of non-functional requirements from
the main functionalities of the application. The use of the WS-* standards
suppose that non-functional requirements are implemented according to the
knowledge that a programmer has of a specific application requirements, without
deriving them in a methodological way, thus leading to \textit{ad-hoc} solutions
that can be difficult to reuse. In our approach, once defined policies for a
given application, they can be reused and/or specialized for another application
with similar requirements.

Considering choreography and orquestration, a detailed description of the
difference between them will be present at Backgroud chapter in the final
version of the thesis' manuscript. These concepts will be described in this chapter,
together with other important concepts, which are: MDA, Service-Oriented
Development, Compositionof Services \cite{NguyenHPCM09} and NFRs
\cite{MylopoulosBook99,UszokBJ04,Chung2009,Yu97,AmyotM02}.

Considering the work proposed by D'Ambrogio \cite{DAmbrogio06} , this
work proposes a WSDL extension for describing QoS in Web Services, describing an
MDA approach with one level of transformation. The work describes not
a methodology proposal, but rather an extension of WSDL using MDA. Thus, we
believe that the proposed D'Ambrogio differs slightly from our approach.    


MDA (Model Driven Architecture) allows the specification of a system as an
abstract model, which may be realized as a concrete implementation (program).
Thus, MDA be typically used in developing service-oriented applications
\cite{AchilleosKP11,CastroMV11,DamascenoLMSSAMRSL11,KaterosKTV08,DAmbrogio06},
and generate code for a particular service description or specification languages,
for exemple, WSDL, WS-BPEL or $\pi$-PEWS.

There are other approaches for service-oriented development (that not
necessaraly usess MDA) such as the DEVISE methodology \cite{DEVISE}, which although not be a
development methodology, it is a methodology for defining infrastructure Web
services. Or even the S-Cube \cite{scube2010book} proposal. 
 
Our approach ($\pi$SOD-M methodology) provides a model-driven structure that
encompasses concepts related with service-oriented development and
non-functional properties. The method provides a set of concepts, steps and
transformations to develop the applications. $\pi$SOD-M provides an development
environment in the context of \textit{Eclipse Modelling}, built as a set of
plugins. The plugins are: \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
$\pi$-SerciveComposition} and \textit{$\pi$-PEWS}, beyond the transformation
plugins. Once the environment is proposed in context of the Eclipse, the
environmental requirements are the same as required by the Eclipse tool. 



\bibliography{respostas}
\bibliographystyle{plain}

\end{document}
